@mladBlum on "master" the version is already on version: 3.4.1 - sorry, did not see that.
In that case you'll have to bump to version: 3.4.2 - even if 3.4.1 is not yet released ..

@mladBlum on "master" the version is already on version: 3.4.1 - sorry, did not see that. In that case you'll have to bump to version: 3.4.2 - even if 3.4.1 is not yet released ..

Sorry, that's on me, I should have checked it myself.

Hey @mladBlum, could you explain what were you trying to achieve with this change?

For us it broke the Ditto authentication as the pre-authenticated header is now not reaching the gateway pod. I am planning to make a PR that would revert this, but maybe there is an opportunity to achieve your goals and our goals at the same time? 😁

Oh, I see #1778. Hm, maybe there could be another way how to do it.

Oh, ouch .. really surprising to me how many of you don't use OAuth based authentication, but rely on that pre-authentication ..

Hey @mladBlum, could you explain what were you trying to achieve with this change?

For us it broke the Ditto authentication as the pre-authenticated header is now not reaching the gateway pod. I am planning to make a PR that would revert this, but maybe there is an opportunity to achieve your goals and our goals at the same time? 😁

Oh, I see #1778. Hm, maybe there could be another way how to do it.

Would be nice if we could solve this issue together. The same text you wrote applied for us before. I just placed the ditto headers into the ingress so that every ingress controller is working. I am really curious about the cause of your problem because this should be a more generic solution.

What is your setup?
Do you use the included ingress controller in the chart?

What is your setup? Do you use the included ingress controller in the chart?

Yes, we do. I am guessing you are not using the ingress controller included with the chart.

For us, what I see is that proxy_set_header directives ended up in the nginx.ingress.kubernetes.io/configuration-snippet of the ingresses and previously they were part of the location-snippet of the nginx-configuration ConfigMap. The end result is that the gateway is complaining with 401. When I returned the proxy_set_header directive manually to the ConfigMap the gateway was satisfied.

The included ingress controller is ingress-nginx/controller and we've pinned v1.9.1 because our kluster is v1.28.

In my perspective, the ConfigMap is the best place for this, so I will provide a rework of the Helm deployment that places these headers in the nginx-configuration ConfigMap. Hopefully you can work with that too.

What is your setup? Do you use the included ingress controller in the chart?

Yes, we do. I am guessing you are not using the ingress controller included with the chart.

For us, what I see is that proxy_set_header directives ended up in the nginx.ingress.kubernetes.io/configuration-snippet of the ingresses and previously they were part of the location-snippet of the nginx-configuration ConfigMap. The end result is that the gateway is complaining with 401. When I returned the proxy_set_header directive manually to the ConfigMap the gateway was satisfied.

The included ingress controller is ingress-nginx/controller and we've pinned v1.9.1 because our kluster is v1.28.

In my perspective, the ConfigMap is the best place for this, so I will provide a rework of the Helm deployment that places these headers in the nginx-configuration ConfigMap. Hopefully you can work with that too.

Ok, that's a little bit strange.
My assumption was that the included ingress controller also uses the proxy_set_header part in the ingress configuration. I'm very curious why he doesn't do that.
Probably we could add the headers in the place where they were before and also in the ingress itself. So both variants work. There are just a uncomfortable feelings to duplicate this configuration.

Please add me to the merge-request with the rework so i can check the changes.